Remarks 

Claims 1-11, 13, 19-23 and 29-47 are currently pending. Claims 12, 14 and 24 
have been cancelled. Claims 45-47 have been added. 

Applicant's attorney Eric Gifford and inventor John Michel conducted a 
telephonic interview with Examiners Michael Thompson and John Weiss on August 7, 
2009 to discuss the rejection of the claims. Applicant thanks the Examiners for taking 
time to discuss the prior art and proposed amendments to clarify Applicant's claims. 

Claims 1-14, 29-33 and 37-40 were rejected under 35 USC 101 as being directed 
to non- statutory subject matter. The claims have been amended to more clearly recite a 
particular machine in the form of a risk management tool on a computer and the specific 
actions performed by the machine. As described at page 8, lines 5-31 in particular and 
throughout the specification and as shown in Figures 4a-b and 5 in particular and in the 
computer generated interfaces show in the other figures, the risk management tool is 
implemented on a computer to perform a variety of risk management tasks. In claim 1, 
the tool combines and ranks Pf and Cf to define prioritized risk factors Rf, calculates an 
associated risk exposure for the risks based on the risk factors Rf, updates the risk factors, 
recalculates the risk exposure and displays the risk exposure in addition to displaying the 
Pf and Cf tables to prompt a user to select the appropriate ratings for identified risks. 
Applicant submits that the method claims as amended recite a "particular machine" and 
constitute statutory subject matter. The Examiner also objected to language in claims 2, 4, 
5 and 6 as being "nonfunctional descriptive material" and in claims 19-24, 34-36 and 41- 
44 as only reciting the "intended use" of the apparatus. Applicant submits that the 
amendments made to more particularly recite the steps performed by the computer- 
implemented risk management tool address these objections as well. 

Claim 1-2, 7-11, 13-14, 29-33 and 42-44 were rejected under 35 U.S.C. 103(a) as 
being unpatentable over Abrahams (2005/0086090) in view of Beverina (2001/0027389). 
Claims 3-6 and 12 were rejected as being unpatentable over Abrahams and Beverina in 
view of Examiner's Official Notice that it is well known to measure negative impacts 
upon projects and to record minutes or topics discussed and the meeting date. Claims 19- 
20, 22-24, 34-36 and 41 were rejected as being unpatentable over Abrahams and 
Beverina in view of Heinrich US 6,895,383, which teaches an intranet for connecting 
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workstations. Claims 21 was rejected as being unpatentable over Abrahams, Beverina 
and Heinrich in view of Examiner's Official Notice that it is well known to measure 
negative impacts upon projects. 

Independent claims 1, 19, 41 and 47 each contain a limitation of "storing a 
probability of occurrence (Pf) table having a plurality of risk categories for the 
development project, each said category having a plurality of table entries corresponding 
to different numeric Pf ratings, each entry including a category-specific standardized 
qualitative probability definition associated with a Pf rating". As shown in Figure 9 and 
described at page 10, lines 3-19 these "categories" may include assembly, engineering, 
hardware, materials, producibility, software, testing, reliability etc. The tool displays the 
Pf table to prompt the user to select the definition that best characterizes the risk for each 
category. The tool then combines the Pf ratings with a severity of consequence Cf rating 
to define a risk factor Rf for each identified risk. 

As stated at page 11, line 14 of the application, "It is important to note that the 
categories 78 are not the identified risks. As a result, it is not necessary for each new 
project to uniquely define specific risk categories and define the probability definition for 
each probability. This would be unwieldy. The probability descriptions 82 are 
standardized, qualitative and detailed to reduce subjectivity of individual engineers and 
select a more accurate risk factor for the current project." 

The "profiles" or "categories" shown in Figures la-lc and discussed in para 
[0033-0034] of Abrahams are best equated to different "development projects" in the 
context of the invention. When faced with a certain situation or problem, a user of 
Abraham's invention would select the closest profile or category and proceed from there. 
The term "category" has very different meanings as used in Abrahams and Applicant's 
invention. Likewise the "levels" of the sub-indented risk tables in Table 1 are not 
categories, these are "entries" for a single generic risk category. For each risk, Abrahams 
uses the same generic Table 1 to determine the likelihood of the risk albeit the inherent or 
residual risk. Abrahams' "risk" is aggregated or lumped, not resolved into a plurality of 
categories as claimed by the Applicant. Furthermore, Table 1 does not have multiple risk 
categories and does not provide " category specific " definitions. Table 1 is generic and is 
applied to all specified risks and risk categories in the same manner. 
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Even assuming (albeit incorrectly) that Abrahams' risks were resolved into 
hardware, software, technology, . . . and equivalent to risk categories as that term is used 
by Applicant, Abrahams still teaches using the same generic Table 1 to assign risk 
likelihoods. If the Abrahams user encounters a hardware risk the user must decide based 
on his or her own subjective assessment whether the risk is "rare", "unlikely", "possible", 
"likely" or "almost certain". If the user encounters a technology risk, he or she repeats the 
same assessment. These "levels" are certainly not category-specific; Table 1 does not 
provide a different definition of "rare" for a hardware risk, a software risk, a technology 
risk and so forth. Furthermore, the terms "rare", "unlikely" etc. are not 'standardized 
qualitative probability definitions', they are undefined. Table 1 itself includes the 
parenthetical "subjective value" under the heading Level. Applicant invites the Examiner 
to compare Applicant's Figure 9 as a representative example of a Pf table with Abrahams 
Table 1, the differences we are claiming are clear. 

Abrahams' risk factors and selection of controls are based on aggregations and 
averages. Paragraph 41 clearly states that the effectiveness of "any preventive controls" 
(again safety terms, not risk mitigations) are aggregated values. This is a cumulative 
value or average value. Likewise, the "cost field is an aggregated field also, and 
expresses the impact of the risked event reduced by all in-place corrective 
controls... aggregated over all corrective controls." Paragraph 58 clearly states that "the 
generic risks in the knowledge base have values for measuring fields (risk inherent 
likelihood, inherent cost of consequence and control effectiveness) that are averages of 
the values used in profiles of various users over time." Applicants calculated risk factors 
and the assigned mitigation activities are based on the resolved Pf ratings for specific 
categories. 

Independent claims 1, dependent claim 34 and claim 41 also recite limitations 
directed at the tool calculating and displaying a chart of the risk exposure over time, 
displaying the Pf and Cf tables to prompt a user to reassess the at least one risk and select 
Pf and Cf, and updating the prioritized risk factors Rf and risk exposure. The mitigation 
activities are then adjusted based on the updated risk factors and project exposure. The 
Examiner cites to Abrahams Figures 5 & 7 and the associated text at para[0041], [0058], 
[0066-0068]and [0071] to reject this combination of steps. Applicant submits that the 
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Examiner is confusing Abrahams updating of values and adjusting of controls available 
in the database for user to create the initial action plan for the current project or action 
plans for future projects with a dynamic assessment and adjustment of the current 
mitigation plan as that plan is implemented. Once Abrahams controls are selected for a 
given project they are not reassessed and adjusted. Furthermore, Abrahams display of a 
"risk record" is simply not the same as displaying a chart of risk exposure versus time. At 
most the risk record shows a snap short of the inherent risk impact cost and the residual 
risk impact cost with the assigned control for a specific, it does not show how the overall 
cost exposure changes with time. Figure 1C displays the "Inherent Cost" and "Residual 
Cost," but nothing in between because the user selects the "Corrective or Preventive" 
controls based on the aggregate assessments from previous risks within the same 
category. Category is defined in paragraph 67 "... serving merely to help logically 
organize the risks." Once the user selects the controls, the user "Creates an action 
plan... to implement the controls (last box of figure 2). There is no suggestion that 
anything happens with the mitigation plan after the action plan is implemented. Figure 5 
also confirms that the action plan is the last item in the process. There is no reassessment 
as the action plan is implemented. Figure 9C also confirms that preselected preventions 
are combined to contribute to the reduction of likelihood. Again, there is no suggestion 
of assessment as the action plan is implemented. Paragraph 0006 says that "the system 
then calculates the effectiveness of predetermined controls needed to either prevent the 
risk or to reduce the consequence of the risk." The assessments are predetermined, there 
is no assessment as the plan is implemented. The risk exposure developed by the 
invention is used as "the means in prioritizing all of the risks of a profile so as to 
determine the order in which to address the various profile risks." (Paragraph 0041) 
Notice, it is not used to show progress of risks as they are mitigated over time. It is used 
for prioritization to determine which action plans should be implemented to control 
specific risks. 

Beverina's invention is associated with terrorism risk. [0002] He attempts to 
calculate "Vulnerability" and consequences associated with an event. [0004] This tool 
tracks "information about actors (individuals and/or groups), physical surroundings, 
historical events and other information." [0010] This program "provides damage 
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assessments to the user.... the consequence calculation portion of the problem can be 
used independently of the risk management process as a whole " [0013] "The user is 
allowed to specify a weapon system and delivery point, in response to which the system 
performs the damage calculations." [0013] Beverina's probability is calculated based on 
threat likelihood and asset attractiveness. [Fig 34] His invention uses a series of 
questions in an expert database to calculate assessments based on past threats. [Fig 14] 
Beverina's invention uses models from other simulations (plug-in models) to determine 
consequences. [0451] The accuracy of his model depends almost wholly on the accuracy 
of plug-in models. There is no user interface for overriding the assessment calculations 
which are not explained. The user is able to modify the attributes of the user defined 
building site, but then must take the results at face value. There is no calculation of risk 
values explained. The user receives information about threat "vectors" and must make 
modifications to the building site to guess whether the changes may make a difference in 
the overall risk. "The most important part of the interface is the dynamic content area. 
This portion of the interface contains the screens that: Interview the user; Allow the user 
to view and modify data; Display results, charts and graphs; and display 3D graphics for 
building the site and simulating it." [0287] "The user is presented with a palette of 
standard 3D construction tools, camera movement options, and structure types to build. 
The countermeasure library and structure types are then read in from the database, and 
the list presented to the user in an appropriate menu so he can select a structure to build." 
[0329] The user does not interact with the assessment calculation and does not know 
what goes into the calculation. If the counter measure library does not contain the user's 
ideas of countermeasures, or the consequences of the "plug-in" model are not to the 
user's likings, then the outcome is certainly without merit. The user is left to believe the 
assessment based on the tool's "simulation and gaming environment in which artificially 
intelligent actors interact with the environment to determine susceptibility to the 
undesired event." [0010] There is no reassessment based on past performance unless the 
models are updated. The invention relies on its plug-in architecture. It's only as good as 
the model that happens to be plugged in and is restricted to the plugged-in model's 
capabilities. 
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Claim 2 and 41 further specify selecting Cf ratings for both cost and schedule 
impact and displaying both cost and schedule exposure. Applicant further notes that the 
cost and schedule impacts are "project-specific amounts". The amounts specified for cost 
in Table 2 are not "project-specific". Table 2 is applicable for each profile or category 
without modification. What is "insignificant" or "minor" is treated as an absolute and not 
tailored to the project. 

Regarding claims 3 and 6 it is neither obvious nor inherent that Abrahams adds or 
reduces categories, depending on the project. As just described above, Abrahams risk are 
aggregated, not resolved into individual categories. There is only one generic category in 
Table 1. Hence, there is no reason and thus mechanism to add or reduce categories. 
Applicant's Pf table may have hundreds of different categories. The administrative user 
down selects to the plurality of categories applicable to the particular project. Paragraph 
[0036] alludes to "more levels or eliminate some of the default levels" but this is not the 
addition or reduction of categories. This simply adds or eliminates levels within a 
category. 

Regarding claims 4, 21 and 41 and 5, 40 and 43 Abrahams aggregates risk impact 
cost as one cost. Applicants claimed inventions takes each of the categories and sub 
categories and multiplies the Pf of each risk and sums the product to get risk exposures 
for the developmental program. This cannot be done by either Abrahams' or Beverina's 
invention since they only capture a single cost impact. Tracking the cost exposure for 
different sub-categories is a significant improvement over the state of the art. 

Regarding claims 30 and 34, both good and bad plans may be stored in the 
Abrahams and/or Beverina invention, but they are not identified as good or bad plans. 
How is the user to know whether the plans were successful? By the nature of the type of 
plans inherent to the Abrahams and Beverina inventions, there is no way of knowing if 
the plans are successful until there is an attempt to circumvent the controls they have in 
place. This information is not captured within their inventions. Our invention captures 
the outcome of mitigation activity attempts. It becomes very obvious that a mitigation 
activity is not successful when the Pf or Cf increases rather than decreases. 
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Regarding claim 33, Abrahams and Beverina inventions have a single activity 
control implementation. There is no mitigation over time and, therefore, there are no 
associated Pf and Cf ratings as the mitigation activities are completed. 

Applicant notes that claims 37-40 were not rejected over any cited art. Applicant 
submits that the claims as amended are allowable over the cited art. 

In claims 39, 41 and 44 as amended and new claims 45 and 46 the tool combines 
the maximum (highest) selected Cf rating with the maximum (highest) selected Pf for the 
one or more risk categories to define the prioritized risk factor Rf for each identified. As 
described above, Abrahams relies on averages/aggregations to determine risk factors. 
Here applicant is specifying a particular manner in which the Pf and Cf are combined 
without averaging or aggregation. The risk factor Rf is the product of the max Pf and the 
max Cf. In this way, the risk of the individual categories is preserved whereas 
averaging/aggregation dilutes or masks the risk. 

New claim 46 is directed to a method for managing risk using a computer- 
implemented risk management tool. The tool is provided with a Pf table having a 
plurality of risk categories for the development project, each said category having a 
plurality of table entries corresponding to different numeric Pf ratings, each entry 
including a category-specific standardized qualitative probability definition associated 
with the Pf rating and a Cf table including cost and schedule impact categories. (See Fig. 
10, page 11, lines 3-22). The tool prompts the user to select a Pf rating for each category 
based on the standardized category-specific definitions and combines the single highest 
Pf rating with the single highest Cf rating to define the risk factors Rf. In claim 47 the Pf 
table includes at least technology, hardware, requirements, testing software and 
producibility categories. 
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Conclusion 

It is respectfully urged that the subject application is patentable over the cited 
references and is now in condition for allowance. 

The Examiner is invited to call the undersigned at the below listed telephone 
number if, in the opinion of the Examiner, such a telephone conference would expedite or 
aid the prosecution and examination of this application. 

Respectfully submitted, 

/Eric A. Gifford #33501/ 
Eric A. Gifford 
Reg. No. 33,501 
520 760-1754 Phone 

Date: August JJ__, 2009 ATTORNEY FOR APPLICANTS 
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